sphinxandthecursedmummyfandomcom-20200216-history
Menu scripting
This page is a cleaned up version of Notes On Menu Scripting, and it was created by Daniel Peake while working for Eurocom. This wiki page is the exact same version that the original menu scripters used for reference, and it was released in 2018 by THQ Nordic together with Euroland and the other data contained in the Authoring Tools DLC. It is publicly reproduced here with permission. = Events = These events are used to give the menu functionality. Please follow the instructions concerning where to place them carefully. JumpToScript The “JumpToScript” event immediately runs the script it is told to. It should generally be placed on the last frame of the script. The event has three data entries: # The hash code of the script to jump to # The hash code of the alternative script to jump to. If specified as anything other than HT_Script_HASHCODE_BASE, this will be used when jumping from the in-game pause menu. If you do not want an alternate jump destination, just put HT_Script_HASHCODE_BASE in. # Binary value: whether the script that the event is placed in is a leading script or a trailing script. This is important, don’t get it wrong. #* 0 = Trailing script #* 1 = Leading script Special case hash codes can be used instead of script hash codes. The current special case hash codes are used for the in-game pause menu. They are: You can also use these hash codes as special case codes in the MenuButton event. MenuButton This event identifies a script as being a button. The event has three data items: # The hash code of the script to run when pressed. Usually a trailing script. # An objective option hash code. # A flag for whether the button is a “''back” button (leave blank if not). The objective option HC is used to identify the button as an option button, i.e. if it is a button that switches stereo on/off or changes the volume. The current hash codes are: Please see “''Button Scripts''” for details on the rules of creating buttons. The MenuButton event has two special case hash codes. These special cases are for the in-game pause menu. If a button’s destination is set as one of these hash codes, the following will happen: These hash codes can also be used in the “JumpToScript” event, so that you can play a trailing animation if desired. MemcardSlot This is almost the same as “MenuButton”. The difference is that this is a special event for memory card slots on MemcardMenus. The event has one data item that lets you choose which slot the button represents. Start at slot 0. Current code only allows for 4 slots. As with “MenuButton”, this event should always be placed on frame 1 of the script. Menu Update The “Menu Update” event should be placed anywhere after frame 1. It is advised that it is placed on frame 2, as this will result in the user getting control of the menu as early as possible. This event has two data fields: #Menu type #Highlight Pointer script The menu type can be set to “Normal menu” or “Text input screen”. These should be set accordingly. The “Highlight Pointer script” should contain the hashcode of the highlight script that is to be used for the menu. The hashcode can be set to HASHCODE_BASE to use normal script highlights (see “Button Scripts”) or set to the hashcode of the script you want to use as a pointer highlight. A pointer highlight is a single highlight which slides between buttons, as opposed to be switched on and off. Button entities must include special datums to use this type of highlight. (see “Button Scripts”) MemcardMenu This is almost the same as “Menu Update”. The difference is that this is a special event for save and load game screens. The event has one data item that lets you choose whether the menu is a save or a load. Don’t check both save and load, that would just be silly. And nothing would happen. LogoScreen This, again, is almost the same as “Menu Update”. The difference is that this is a special event for logo screens displayed when you start up the game. The event should be placed in the same manner as a normal “Menu Update” event. It should also be placed at frame 0 of any leading script for the logo screen. [ See “Creating Logo Screens” ] CharacterButton This event is used in a similar way to “MenuButton”. It is used for individual letters on text input screens. Each letter on the screen must have a script with one of these events in. There is one data field in this event which contains the character the script represents. [ See “Text Input Screens” for detailed information ] =Basic Structure= Below is an example menu structure. ''Explanation: (included in order to confuse the unwary) : When run, the leading script of M1 is run, and it takes us to menu M1. Menu M1 has three buttons pointing to three separate trailing scripts. These scripts, in turn, point to the leading scripts of M2, M3 and M4. Menus M3 and M4 each have a single button in them pointing to their respective trailing scripts. Both of these scripts point back to the leading script of M1. Activating the button in menu M3 or M4 then, will take you back to M1. Menu M2 has two buttons; one will take you to M1 and the other to M5. M5, again, has a single button. Its trailing script is pointing at M2’s leading script. Thus, pressing the button in M5 would take you back to M2. : Please note that this is not the only way to structure the scripts. For example, it is entirely possible to have a single script that will both trail one menu and lead the next. This is not ideal for all situations however. Leading scripts A menu must have a minimum of one leading script. This is the script that should be called if you want to start the menu. The leading script is generally used to zoom or fade in the menu. A leading script must contain a “JumpToScript” event, which must be placed on the last frame of the script and must point at the menu itself. It must not contain any form of run control. [ See definition of “JumpToScript” ] Trailing Scripts A menu uses trailing scripts in order to play zoom or fade out animations. Generally, when they are used, there will be a trailing for every button in the menu. The trailing script must contain a “JumpToScript” event, which must be placed on the last frame of the script and must point to the leading script of the desired sub menu. It must not contain any form of run control. The Main Script The main script contains the menu. It should''' contain: *''Run control'': Infinite loop *''Event'': Menu Update *''Subscripts'': The menu options / buttons Button Scripts There are three types of button: normal button, option button, and memory card slots. Memory card slots are slightly different to the other two in that they have their own event. These scripts are the actual menu items. They should contain: *A “MenuButton” or “MemcardSlot” event *A highlight subscript *Any other subscript required by the button type (see thread descriptions) In your button script the first three threads are for special use. Depending on what type of button you are making you must only put certain types of subscript on each of them. [ Thread descriptions and pointer highlights over leaf ] Thread 0: * This thread is used for the highlight subscript on all buttons Thread 1: *For option buttons: ** This thread’s for switch markers (i.e. on/off markers etc) * For memory card slots: ** This thread’s for an empty slot marker Thread 2: * This thread’s only for memory card slots and is for corrupt slot markers. [ See definition of “MenuButton” ] If the button is to be used with pointer highlights (see “Menu Update”), the button entity must have a datum attached to it. The pointer highlight will be placed on these datums. The datums can have one of four hashcodes depending on how the pointer should be rotated: Creating Logo Screens A logo screen is a screen that just waits for the user to press start. It can be created like any other menu, with a few alterations: *The leading script should have the “LogoScreen” event on frame 0 *The main script should have a button script (not necessary to be visible) which points to the trailing script. *The main script should also have a “LogoScreen” event, but placed at frame 2, as with “Menu Update” events Text Input Screens Text input screens are a pain to set up, so I suggest you modify the screen in my demo front end rather than create your own. Here is how they work: Each character must have it’s own script. In the script should be two things: #A highlight subscript or entity on thread 1 #A “CharacterButton” event (data field containing the button’s character) The CharacterButton event should be placed the same as a normal button script. The highlight entity should have a datum with the HT_AnimDatum_Character hashcode. The datum should be placed where you want the character to appear. There only needs to be one highlight for all characters. All of the character scripts should then be put in a character screen script, along with the usual events (back buttons, menu update events etc). Not that the “Menu Update” event’s first data field (“Menu Type”) should be set to “Text input screen”. Option Buttons Option switches: This type of button is used for on/off switches (e.g. stereo/mono, rumble/no rumble). * Thread 1 of the script is visible if the option is off, invisible if the button is on. Here is a suggestion of how to layout the button script. * Thread 0 contains the highlight (as with all buttons). * Thread 1 contains the label that will be displayed when the option is off. Notice that it is above the on label, so that when the thread is invisible (and the option is on), the on label is revealed. Volume sliders: In volume sliders, the entity or script on thread 1 is resized by the game to represent the current volume. Note that the entity or script is simply sized along the ''x''-axis, meaning that to create the illusion of a bar growing and shortening, the origin of the script or entity should ''not''''' be in the centre of the object: For examples, see FrontEnd.elf. Category:Game development